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Since its founding, NASA has been dedicated to the 
advancement of aeronautics and space science. The 
NASA Scientific and Technical Information (STI) 
program plays a key part in helping NASA maintain 
this important role. 

The NASA STI Program operates under the auspices 
of the Agency Chief Information Officer. It collects, 
organizes, provides for archiving, and disseminates 
NASA’s STI. The NASA STI program provides access 
to the NASA Aeronautics and Space Database and its 
public interface, the NASA Technical Reports Server, 
thus providing one of the largest collections of 
aeronautical and space science STI in the world. 
Results are published in both non-NASA channels and 
by NASA in the NASA STI Report Series, which 
includes the following report types: 

• TECHNICAL PUBLICATION. Reports of 
completed research or a major significant phase 
of research that present the results of NASA 
programs and include extensive data or theoretical 
analysis. Includes compilations of significant 
scientific and technical data and information 
deemed to be of continuing reference value. 
NASA counterpart of peer-reviewed formal 
professional papers but has less stringent 
limitations on manuscript length and extent of 
graphic presentations. 

• TECHNICAL MEMORANDUM. Scientific 
and technical findings that are preliminary or 
of specialized interest, e.g., quick release 
reports, working papers, and bibliographies that 
contain minimal annotation. Does not contain 
extensive analysis. 

• CONTRACTOR REPORT. Scientific and 
technical findings by NASA-sponsored 
contractors and grantees. 


• CONFERENCE PUBLICATION. Collected 
papers from scientific and technical 
conferences, symposia, seminars, or other 
meetings sponsored or cosponsored by NASA. 

• SPECIAL PUBLICATION. Scientific, 
technical, or historical information from 
NASA programs, projects, and missions, often 
concerned with subjects having substantial 
public interest. 

• TECHNICAL TRANSLATION. English- 
language translations of foreign scientific and 
technical material pertinent to NASA’s mission. 

Specialized services also include creating custom 

thesauri, building customized databases, organizing 

and publishing research results. 

For more information about the NASA STI 

program, see the following: 

• Access the NASA STI program home page at 
http://www.sti. nasa.gov 

• E-mail your question via the Internet to 
help@sti. nasa.gov 

• Fax your question to the NASA STI Help Desk 
at 301-621-0134 

• Telephone the NASA STI Help Desk at 
301-621-0390 

• Write to: 

NASA Center for AeroSpace Information (CASI) 
7115 Standard Drive 
Hanover, MD 21076-1320 
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Summary 

This report defines a hardware architecture approach for 
software-defined radios to enable commonality among NASA 
space missions. The architecture accommodates a range of 
reconfigurable processing technologies including general- 
purpose processors, digital signal processors, field program- 
mable gate arrays, and application-specific integrated circuits 
(ASICs) in addition to flexible and tunable radiofrequency 
front ends to satisfy varying mission requirements. The 
hardware architecture consists of modules, radio functions, 
and interfaces. The modules are a logical division of common 
radio functions that compose a typical communication radio. 
This report describes the architecture details, the module 
definitions, the typical functions on each module, and the 
module interfaces. Tradeoffs between component-based, 
custom architecture and a fimctional-based, open architecture 
are described. The architecture does not specify a physical 
implementation internally on each module, nor does the 
architecture mandate the standards or ratings of the hardware 
used to construct the radios. 


Hardware Architecture 

In addition to providing many benefits by defining a stan- 
dard software infrastructure for NASA’s radios, the Space 
Telecommunications Radio System (STRS) architecture 
defines standards for the hardware portion of the radio. 
Hardware technologies usually change more rapidly than 
software, and they tend to be more spacecraft dependent. 
Therefore, the STRS hardware architecture is specified at a 
functional level. However, each class of missions has the 
latitude to standardize more at the implementation level. 

The STRS hardware architecture was developed consider- 
ing several constraints and conditions for the operation of 
space software-defined radios (SDRs). One major requirement 
driving the hardware architecture formulation is the need for 
flexibility, so that one architecture can address the range of 
different mission classes. These mission classes range from 
requiring small radios that are highly optimized to meet severe 
size, weight, and power constraints, to missions requiring 
complex radios with multiple operating frequencies and higher 
data rates. This diversity requires that the architecture 
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accommodate a range of reconfigurable processing technolo- 
gies including general-purpose processors (GPPs), digital 
signal processors, field programmable gate arrays (FPGAs), 
and application-specific integrated circuits (ASICs) with 
selectable parameters. Currently, reconfigurable signal 
processing is primarily performed in specialized signal- 
processing hardware for the frequencies and data rates used in 
NASA space missions, and this is expected to continue for 
some time. In addition to providing capability, specialized 
signal processing is generally more power efficient than 
general-purpose processing. Likewise, the use of FPGA-based 
specialized signal processing is generally more power efficient 
than Digital Signal Processing (DSP). The needs for special- 
ized processing are supplemented by the software infrastruc- 
ture, which is more suited for execution in a general-purpose 
processor. Another requirement is that the hardware and 
software architecture enable technology infusion over time. 
This is a key point of the hardware architecture, since the 
capabilities of the radios are rapidly evolving as processor 
speeds and capabilities increase. In addition, the conversion 
point, where the signal is digitized, is moving closer to the 
antenna. Because of these points, the architecture was 
designed to provide a flexible framework but not to prescribe 
a specific hardware implementation approach. 

Generalized Hardware Architecture and 
Specification 

Figure 1 illustrates the symbols and terminology used in the 
hardware architecture diagrams. The diagrams show the 
modules, radio functions, and interconnects. The modules are 
logical and functional divisions of the common radio functions 
that compose an STRS radio. Modules are not intended to 


represent the physical entities of the radio. As developers 
choose how to distribute the radio functions among hardware 
elements, the specification provides guidance on the interfaces 
and abstractions that must be provided to comply with the 
architecture. The module and function connections provided in 
the diagrams are data path, control path, clock signal, system 
bus, and external interfaces. 

Figure 2 shows the high-level STRS hardware architecture 
diagram. The diagram shows the modules, functional attri- 
butes, and interfaces for each module. A module is a combina- 
tion of logical and functional representations of platform and 
waveform functions implemented in a radio. The diagram 
divides the modules into the functions typically associated 
with the module to provide a common description and 
terminology reference. The radio developer has the flexibility 
to combine these modules and their functionality as necessary 
during the radio design process to meet the specific mission 
requirements. Additional modules can be added for increased 
capability. 

The architecture does not specify a physical implementation 
internally on each module, nor does it mandate the standards 
or ratings of the hardware used to construct the radios. Thus 
the radio supplier can incorporate company proprietary circuit 
or software designs, provided the modules meet the specific 
architecture rules and interfaces defined for each module. For 
example, all radiofrequency (RF) and signal-processing 
components or functions may be integrated onto a single 
printed circuit board, easing footprint, interface, and integra- 
tion issues. However, a large mission class may choose to 
standardize the Radio Frequency Module to Signal-Processing 
Module (RFM-to-SPM) interface. This might be done to 
facilitate the use of different RFMs with the same SPM across 
several similar missions. Each mission or class of missions 


Internal Connections 

Data Path 

Control Path 

Clock Signal 
System Bus 

External Connections 
Data Path 
Control Path 
Clock Signal ^ 
Ground Test 


Modules Radio Functions 


General 
Processing 
Module (GPM) 



Signal 
Processing 
Module (SPM) 



External Interface 


Radio 
Frequency 
Module (RFM) 


Figure 1. — Hardware architecture diagram key. 
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Figure 2. — Space Telecommunications Radio System (STRS) hardware architecture diagram. HAL, 
Hardware Abstraction Layer; API, application programming interface. 


may choose to standardize certain interfaces and physical 
packaging. This approach provides NASA with the flexibility 
to adopt different implementation standards for various 
mission classes. Thus, if a series of radios are required with com- 
mon operating requirements, physical construction details — 
such as the bus chassis or card slice — can be part of the 
acquisition strategy, for cost-effective modularity at a lower 
level to match the life cycle of the hardware. 

Not all the elements depicted in the generalized architecture 
are required for implementation. This architecture specifies (at 
a high level) how implementations will meet these elements, 
but it does not necessarily specify when to implement them. 
Mission requirements will dictate the necessity of any 
particular element. 

Components 

This standard describes the STRS hardware architecture in 
a modular fashion. The generic hardware architecture diagram 
(fig. 2) identifies three main functional components (or 
modules) of the STRS radio: the General Processing Module 
(GPM), the SPM, and the RFM. Although not shown in 
figure 2, additional modules (e.g., optical, networking, or 
security) can be added for increased capability and will be 


included in the specification as it matures. Descriptions of the 
modules used follow: 

General Processing Module (GPM) 

The GPM consists of the general-purpose processor, appro- 
priate memory (both volatile and nonvolatile), system bus, the 
spacecraft (or host) tracking, telemetry, and control (TT&C) 
interface, ground support telemetry and test interface, and the 
components to support the radio configuration. 

Signal-Processing Module (SPM) 

The SPM contains the implementations of the signal process- 
ing used to transform received digitally formatted signals into 
data packets and/or convert data packets into digitally formatted 
signals to be transmitted. Also included is the spacecraft data 
interface. Components include ASICs, FPGAs, digital signal 
processors, memory, and connection digital fabric bus. 

Radio Frequency Module (RFM) 

The RPM handles the RF functionality to provide the SPM 
with the filtered, amplified, and digitally formatted signal. For 
transmission, it formats, filters, and amplifies the output 
signal. Its associated components include filters, RF switches, 
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diplexer, low-noise amplifiers (LNAs), power amplifiers, 
analog-to-digital converters (ADCs), and digital-to-analog 
converters (DACs). This module handles the interfaces that 
control the final stage of transmission or the first stage of 
reception of the wireless signals, including antennas. 

Security Module 

Although not directly identified in the generic hardware 
diagram, a security module is also being proposed to allow 
STRS radios to support future security requirements. 

Network Module 

The architecture supports Consultative Committee for 
Space Data Systems, Internet Protocol, and networking 
functions. However, the Network Module may be realized as a 
combination of both the GPM and SPM. 

Functions 

The following functions shall be common to all modules: 
Test and Status 

Each module (or combination of modules) shall provide a 
means to query current health and run diagnostics. 

Fault Monitoring and Recovery 

Each module shall incorporate detection of operational 
errors, upsets, and major component failures. These may be 
caused by the radiation environment (e.g., single-event upset 
temperature fluctuations, power supply anomalies, or other 
conditions). In addition to detection, mitigation and fail-safe 
techniques shall be employed. Each module shall have a 
default powerup mode to provide the minimal functionality 
required by the mission. This fail-safe mode shall have 
minimal software/firmware dependency. 

Radio Data Path 

A key aspect of this architecture is the separation of the 
RFM-to-SPM data path from the GPM. SDRs can be imple- 
mented, and have previously been implemented, with the 
GPM in the data path. Giving the GPM access to the data path 
as an optional capability rather than as a required capability 
allows for a more efficient implementation for medium and 
small mission classes and improves overall performance for 
near-term implementations. Once space-qualified GPM com- 
ponents mature with the performance capabilities required for 
signal processing, the GPM can exist within the data path and 
take on more signal-processing functionality, increasing 
flexibility. This is a foreseen evolution of the architecture 


because some SDR implementations take that approach 
already and experiment versions using that approach have 
been flown in space for the past few years. 

External Interfaces 

There are several key external interfaces in this architecture: 
TT&C Interface 

The host TT&C interface represents the typically low- 
latency, low-rate interface for the spacecraft (or other host) to 
communicate with the radio. The host telemetry typically 
carries all information sourced by the radio. This type of 
information traditionally is called the telemetry data and 
includes health, status, and performance parameters of the 
radio as well as the link in use. In addition, this telemetry 
often includes radiometric tracking and navigation data. The 
telecommand portion of this interface contains the information 
that has the radio itself as the destination of the information. 
Configuration parameters, configuration data files, new soft- 
ware data files, and operational commands are the typical 
types of information found on this interface. 

Telemetry and Test Interface (for Ground Use) 

This interface provides a development-level view of the 
radio and is used exclusively for ground-based integration and 
testing functions. It typically provides low-level access to 
internal parameters not typically available to the spacecraft 
TT&C interface. It can also provide access when the GPM is 
not functioning (i.e., during boot). 

Data Interface 

This is the primary interface for data that are sourced from 
the other end of the link and for data that are sunk to the other 
end of the link. This interface is separate from the TT&C 
interface because it typically has a different set of transfer 
parameters (protocol, speeds, volumes, etc.) than the TT&C 
information. A common interface point in the spacecraft for 
this type of interface is the spacecraft solid-state recorder 
rather than the spacecraft command and data-handling sub- 
system. This interface is also characterized by medium to high 
latency and high data rates. 

Clock Interface 

This interface is used to input to the radio the frequency 
reference sufficient for supporting navigation and tracking. 
This type of input frequency reference is essential to the 
operation of the radio and provides references to the SPM and 
RFM. 
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Antenna Interface 

This interface is used to connect the electromagnetic signal 
(input or output) to the radiating element or elements of the 
spacecraft. It also includes the necessary capability for 
switching among the elements as required. Steering the 
elements, if a function of the overall telecommunications 
system, is possible through this interface, but it is not typically 
employed because of overall operational constraints. 

Direct-Current (dc) Power Interface 

Although not included on the diagram, the power interface 
is described as part of this specification at the highest level. 
The power interface defines the types and conditions of the 
input energy to power the radio. 

Networking Interface 

As described in the overview, a networking interface does 
not necessarily map directly to the hardware modules 
specified. In the case where the networking interface handles 
spacecraft TT&C data only, the TT&C interface is subsumed 
into the networking interface. There are times; however, when 
it will be desired to interface both the TT&C data and the 
radio data through the same networked interface. This 
architecture allows for that capability if the GPM has enough 
capacity to accomplish those tasks. 

Internal Interfaces 

There are several interfaces internal to the modules and 
between the modules and functions themselves. These key 
internal interfaces must be defined in an open manner to support 
the overall goals of the architecture; however, constraining them 
at a low level can reduce the overall capabilities of the radio. 
Note that the colors refer to the line colors in figure 2. 

GPM System Bus (Orange Lines) 

The GPM system bus provides the primary interconnect 
between elements of the GPM and should be implemented as 
the system bus of the GPM microprocessor by the system 
control architecture block. As well as providing an interface 
between the microprocessor and the memory elements of the 
GPM, the GPM system bus provides interconnect to the 
TT&C and the telemetry and test external interfaces. The 
GPM system bus is the primary interface between the GPM 
and the SPM, as shown in the interconnection with the major 
SPM processing elements. Finally, the GPM system bus 
provides the interface by which the reprogrammable and 
reconfigurable elements of the SDR are modified. It supports 
read and write access to the SPM elements as well as the 
reloading of configuration files to the FPGAs. 

GPM-to-RFM Control (Blue Lines) 

The interface between the GPM and the RFM is primarily a 
control and status interface. Various RFM elements are 


controlled by the set of GPM-to-RFM control lines. Coming 
from the system control block in the GPM, this control bus 
can be either fixed by the system control function or pro- 
grammed by the GPM software and validated and routed 
by the system control function. It is important to have a 
hardware-based confirmation and limit check on the software 
controlling any RFM elements. The system control module of 
the GPM provides this functionality, thus keeping the GPM- 
to-RFM control bus within operational limits. 

SPM-to-GPM Test and Status (Blue Lines) 

This interface provides specific control and status signals 
from different modules or functions to the ground test 
interface block. These interfaces are used during development 
and testing to validate the operation of the various radio 
functions. This interface is also very specific to the implemen- 
tation and realization of the different modules and is general- 
ized in the telemetry and test interface block as required. 

Frequency Reference Interface (Tan Lines) 

This is an important interface between the RFM and the 
SPM functions. It ties the two modules together in a way that 
allows for the SDR to implement tracking and navigation 
functions. The characteristics of this interface are defined by 
the various amounts of tracking accuracy that the SPM must 
accomplish. This interface can be as simple as a single, 
common frequency reference that is conditioned from an 
outside source and distributed in the least degrading fashion 
possible to the SPM. 

Data Paths (Black Lines) 

These are the various streams of bits, symbols, and RF 
waves connecting the major blocks of the primary data path. 
For any particular implementation, the particular waveform 
implemented in the functional blocks define the data path 
or bitstreams. The interface between the RFM and SPM, 
however, should be well-defined and have characteristics 
suitable for that level of conversion between the analog and 
digital domains. 

If the implementation dictates the necessity of particular 
components, the hardware architecture can be further specified 
in a manner that is important for implementers to consider and 
follow. Details of the GPM, SPM, and RFM are provided in 
the next section. 

Module Type Specification 

General Processing Module 

The GPM consists of one or more general-purpose or DSP 
elements and support hardware components, an embedded 
real-time operating system (RTOS), software applications, and 
interfaces to support the configuration, control, and status of 
the radio. The number of processing elements and the extent 
of support hardware will vary (depending on the mission class 
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processing and data-handling requirements) from a single 
system on a chip implementation for smaller mission classes 
to multiple logical replaceable units for the largest mission 
classes. In addition, the fault-tolerance requirements can 
increase the number of hardware processing elements, support 
hardware components, and interface points required to meet 
the range of mission classes. It is anticipated that the majority 
of processing functions of the GPM will be under software 
control and supported by an RTOS. 

General Processing Module Components 

The GPM contains, as necessary, a general-purpose proces- 
sor and various memory elements. Depending on the particular 
mission implementation class, not all memory elements are 
required. The general-purpose processor will typically be 
implemented as a microprocessor, but it could take many 
forms, depending on the mission class. 

The persistent memory storage element holds both the 
permanent (e.g., programmable read-only memory (PROM)) 
and reprogrammable code for the general-purpose processor 
element. Currently, this code is implemented using a repro- 
grammable technology such as electrically erasable, pro- 
grammable read-only memory (EEPROM). It is also possible, 
but not typically qualifiable, to implement this code storage in 
flash memory. The persistent memory also provides the 
reprogrammable storage for the SPM FPGA elements (i.e., 
SPM firmware). The GPM is responsible for programming 
and scrubbing the SPM FPGAs to ensure the appropriate code 
for the FPGAs. This memory block is typically implemented 
using a nonvolatile memory technology such as EEPROM but 
could, in particular implementations, be implemented with 
PROM technology. 

The workarea memory element is provided as operational, 
scratch memory for the general-purpose processor element. 
This memory element is implemented in concert with the 
general-purpose processor element and may contain both data 
and code, as appropriate for the execution of the radio 
application running in the GPM. 

Finally, the GPM contains a system control element to 
control and moderate the GPM system bus. This element 
provides the necessary control for the system bus, including 
the various memory and SPM elements interfaced by the 
system bus. In addition, the system control element provides a 
validated interface to the RFM hardware via the GPM-to-RFM 
control interface. As the software running on the general- 
purpose processing element commands the RFM elements into 
certain states, those commands must be interpreted by the 
system control element and validated in a manner that pre- 
vents damaging configurations of the RFM: for example, tying 
the transmit amplifier directly to the receive amplifier, 
bypassing the diplexer element. This level of validation has to 
be present in the GPM-to-RFM interfaces to prevent the radio 
from being damaged by a software bug. The system control 
element is typically implemented by a nonreprogrammable (in 


flight) FPGA allowing for flexibility between instantiations of 
a particular implementation. 

General Processing Module Functions 

The GPM provides the overall configuration and control of 
the STRS architecture and may include any or all of the 
following functions: 

■ Management and control 

- Module discovery 

- Configuration control 

- Command, control, and status 

- Fault recovery 

- Encryption 

■ STRS infrastructure, radio configuration, and control 

- Radio control 

- System management 

- Waveform upload management 

- Device control 

- Message center 

■ External network interface processing 

■ Internal data routing 

■ Waveform data link layer 

- Media Access Control (MAC) and Fogical Fink 
Control (EEC) layer 

- Physical layer processing 

■ Onboard data switch 

General Processing Module Interfaces 

■ TT&C interface 

■ Telemetry and test interface 

■ Programmable General-Purpose Input/Output (GPIO) to 
support 

- Interrupt source and sink 

- Application data transfer 

■ Control and configuration interfaces — RFM, antenna, 
power amplifier, and SPM 

■ System bus interface 

The GPM configuration file shall describe the hardware 
environment for the STRS architecture. It will identify the 
existence of the different hardware modules and their 
associated configuration files that will allow the architecture 
to instantiate drivers and test applications. 

Hardware Interface Definition 

The following performance capabilities of the GPM shall be 
provided by the hardware developer: 

■ Processing capability — Microprocessor clock speed or 
Microprocessor without Interlocked Pipeline Stages (MIPS) 

■ Data input/output (I/O) rate maximum in bits per second 
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Signal-Processing Module 

The SPM implements the signal processing used to trans- 
form received digital signals into data packets and/or convert 
data packets into digital signals to transmit. The complexity of 
this module can be varied according to the waveforms and data 
rates selected for a mission. The SPM contains components and 
capabilities to manipulate and manage digital signals that 
require higher processing capabilities than that supplied by the 
GPM. The SPM will rely on Hardware Abstraction Layer 
(HAL) drivers to present consistent interfaces to the waveform 
applications in processing and distributing data. 

Signal-Processing Module Components 

The SPM may be implemented primarily with FPGAs, 
DSPs, reconfigurable processors, ASICs, and other integrated 
circuits. However, technologies will change over time, so the 
specific implementation is left to the platform vendor. 

It is also anticipated that STRS radios will use dedicated 
SPM slices for specific waveforms and technologies. For 
example, a dedicated Global Positioning System (GPS) 
receiver slice could complement the existence of reconfigur- 
able SPM slices in the same radio. The dedicated slice 
offloads demands on the less specific SPM. All slices would 
still meet the module interface specifications to allow for 
control and configuration. 

Each element of the SPM contains an interface with the 
GPM via the GPM system bus and the SPM-to-GPM test 
interface. These two interfaces work in concert to provide a 
control and reconfiguration and reprogramming data path to 
the SPM from the GPM and the radio application running in 
the GPM. 

Signal-Processing Module Functions 

The DSP function, which is used to convert symbols to bits 
(and vice versa), is typically partitioned between an ASIC and 
an FPGA; however, either element can exist by itself in the 
SPM. In many cases, it may be appropriate for the bulk of the 
DSP to be implemented in an ASIC (may be a nonprogram- 
mable FPGA) and to have an associated reprogrammable 
FPGA in the data path but not actually implementing any DSP 
functionality at the onset of the implementation. Having a 
reprogrammable element in the data path allows for new 
capability to be added to the SDR in the future without 
hardware redesign. 

In addition to the DSP function, a data-formatting function 
is required to convert blocks of data stored in the data storage 
element into bitstreams appropriate for encoding into symbols 
(and vice versa). In many cases, it is possible to implement the 
data-formatting function in the same device as the DSP 
function, but that is an implementation detail dependent on the 
mission class. 

A data storage element is used to provide a queuing buffer 
between the data interface and the bitstream coders and 
decoders. This function can be implemented in either volatile 
or nonvolatile memory, depending on the requirements of the 


mission implementation. An SPM may implement any or all 
of the following digital communication functions depending 
on the mission waveforms: 

Digital upconversion . — This involves interpolation, filter- 
ing, and multiplication of baseband samples to obtain an 
intermediate frequency (IF) or RF output sample stream that is 
appropriate for digital-to-analog conversion. This is typically 
the last transmit function implemented in the SPM, and the 
output samples are sent to the RFM. 

Digital downconversion. — This function involves multipli- 
cation with the local oscillator, downsampling, and filtering IF 
or RF samples to obtain a baseband output sample stream. 
This is typically the first receive function implemented in the 
SPM, with input samples coming from the analog-to-digital 
conversion in the RFM. 

Digital filtering . — This is done with averaging, low-pass, 
high-pass, band-pass, polyphase, and other filters used for 
pulse shaping, matched filter, and other functions. This may 
overlap with some of the functionality in the upconversion and 
downconversion. 

Carrier recovery and tracking. — This involves retrieval of 
the waveform carrier within the receive sample stream, and 
shifting recovered carrier frequency to accommodate local 
oscillator differences and Doppler shifts in the link. 

Synchronization (data, symbol , etc.). — This aligns the 
received samples with symbol and data boundaries. There may 
some integration with the digital downconversion and carrier 
recovery and tracking functions. 

Forward error correction coding . — This function encodes 
transmit data so that receive data errors may be corrected to 
some level, enhancing the waveform performance. 

Digital automatic gain control . — This function scales the 
receive samples to optimize downstream operations. 

Symbol mapping (modulation ). — This function translates 
transmit data bits to modulation symbol samples. 

Data detection (demodulation). — This functions translates 
receive symbol samples to data bits. 

Spreading and dispreading . — This is a form of encoding 
data to obtain certain energy dispersion in the frequency 
domain. 

Scrambling and descrambling . — This is a form of encoding 
data to ensure a certain level of randomness in the digital data 
stream, usually for synchronization of the receiver. 

Encryption and decryption. — This is a form of encoding 
data for security purposes. 

Data I/O (high-speed direct from or to source or sink ). — 
This is the interface for transmit and/or receive data to come in 
or out of the module. This may require buffering and some 
protocol handling. 

Signal-Processing Module Interfaces 

Interfaces shown in figure 2 include those common to all 
module types as well as those specific to the SPM. Some 
missions may not require all of these SPM-specific interfaces. 
All implemented interfaces shall be specified in the hardware 
interface description (HID). Note that the implementation of 
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these interfaces may combine two or more interfaces on one 
physical transport. For example, the data interface and the 
control and configuration interface may both use the same 
physical Serial RapidIO (interconnect technology) connection. 

Data I/O to or from RFM. — This is the digital sample 
stream going to the RFM’s DAC(s) for transmission, and the 
digital samples from the RFM’s ADC(s). However, if the 
DACs and ADCs are preferred to be a part of the SPM, then 
this interface is replaced with analog baseband or IF signals. 

Waveform control and feedback to RFM. — This interface 
will be waveform dependent. It may be used, for example, to 
send feedback to an automatic gain control or to control 
frequency hopping. 

Data interface external to the radio. — High-data-rate 
waveforms may need a direct interface to the SPM if the GPM 
is not designed to handle the data. 

System bus — data to and from the GPM. — This interface 
exchanges the packetized data for transmission and reception. 

Control and configuration from GPM. — Waveform loads 
and reconfigurable parameters are managed through this 
interface. 

Test and status to GPM. — Tests are initiated through this 
interface by the GPM, and results are returned. This is a more 
basic interface (electrically and protocol-wise) than the control 
and configuration interface. 

Hardware Interface Definition 

The following performance capabilities of the SPM shall be 
provided by the hardware developer: 

■ Processing capability — Microprocessor clock speed or 
MIPS 

■ Reconfigurable capacity — FPGA gates or Configurable 
Logic Blocks 

■ Data I/O rate maximum in bits per second 

Radio Frequency Module 

The RFM handles the conversion to and from the carrier 
frequency, providing the SPM and/or the GPM with digital 
baseband or IF signals, and the transmission and reception 
equipment with RF to support the SPM and GPM functions. 
Its components currently include DACs, ADCs, RF switches, 
upconverters and downconverters, diplexer, filters, LNAs, and 
power amplifiers. Current and near-term RF technologies 
cannot expect to solve for multiband operation using a single- 
channel RFM, and thus multiband radios will need to use 
multiple RFM slices. The RFM provides a band of frequency 
tunability on each slice. This tunability can be software 
controlled through the provided interfaces. 

The RFM handles the interfaces that control the final stage 
of transmission or first stage of reception of the wireless 
signals, including antennas, optical telescopes, steerable 
antennas, external power amplifiers, diplexers, triplexers, and 
RF switches. These external radio equipment components 


would otherwise be integrated with the RFM except for the 
physical size and location constraints for transmission and 
reception. The interfaces involved are primarily their associ- 
ated control interfaces. The RFM HID encompasses the 
control and interface mechanism to the external components. 
The focus of the RF HID is to provide a standardized interface 
to the control of each of these devices in order to synchronize 
the operation of the radio with any of these devices. 

The other primary capability of the RFM is the conditioning 
and distribution of the frequency reference as defined by the 
frequency reference interface. This provides a common 
reference for the RFM and SPM to enable the tracking and 
navigation functionality required of SDRs. 

Radio Frequency Module Functions 

The required functions of the RFM follow: 

■ The RFM shall provide for frequency conversion. 

■ The RFM shall support security measures controlled by 
the GPM or SPM to prevent inadvertent and unauthor- 
ized commanding or modification of data. 

■ The RFM shall be capable of providing IF analog output 
and input analog signal. 

■ The RFM shall provide for radiometric tracking. 

Radio Frequency Module Interface 

The RFM provides read and write access to interface regis- 
ters to monitor and perform control, status, and failure and 
fault recovery functions (via RS-422 or Space wire), including 

■ Control (power-level tunability, frequency tunability, 
antenna parameter tunability, etc.) 

■ Status (maintain status of components and system 
operation) 

■ Failure and fault recovery functions (detect component 
or system failure and determine appropriate action) 

It also provides diagnostic test registers and I/O for exchang- 
ing digitized waveform signal data. 

Hardware Interface Definition 

The following performance capabilities of the RFM shall be 
given by the hardware developer: 

■ Tunable carrier frequency range (in each band) 

■ Number of simultaneous bands or carriers or channels 

Mission Class Examples 

The STRS Description Document 1.0 (ref. 1) identifies a set 
of candidate platform profiles (e.g., low, medium, and high) 
designed to meet various NASA mission requirements. This 
classification is not meant to infer that they are physically 
independent units. This approach provides NASA with the 
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Figure 3. — Large-mission-class STRS hardware realization. 
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Figure 4. — Medium-mission-class STRS hardware realization. 


flexibility to adopt different implementation standards for 
various mission classes. Thus, if a series of radios are required 
with common operating requirements, physical construction 
details, such as bus chassis or card slice, can be part of the 
acquisition strategy for cost-effective modularity at a lower 
level to match the life cycle of the hardware. 


The STRS architecture hardware configurations can be 
realized to support a variety of mission-class-driven imple- 
mentations. This section shows three possible realizations as 
an example; however, they do not represent the only represen- 
tations available. Figures 3 and 4 show large- and medium- 
mission-class examples. 
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Figure 5. — Alternative medium-mission-class STRS hardware realization. RFM, Radio Frequency Module; SPM, 
Signal-Processing Module; GPM, General Processing Module; PCI, Peripheral Component Interconnect; 1C, 
integrated circuit; NCO, Numerically Controlled Oscillator. 


Figure 5 depicts another medium-mission-class STRS 
architecture partitioning. This STRS platform is highly 
modular, consisting of one GPM, an SPM capable of simulta- 
neously processing two received signals and three transmitted 
signals, an RFM with two receiver chains and three transmitter 
chains, together with the supporting power supply, chassis, 
cabling, and power amplifiers. There are two separate S-band 
receiver RF chains, for simultaneous operation of two S-band 
waveforms such as the Tracking and Data Relay Satellite 
System (TDRSS) and space-to-space links. Similarly, there are 
two separate S-band transmitter chains, one for each S-band 
transmit waveform, to enable simultaneous operation of these 
links. The third transmitter chain depicted in figure 5 is an 
X-band transmitter for high-rate telemetry or mission data. 


The SPM contains a signal-processing ASIC, a high-density 
reprogrammable FPGA, a programmable digital signal processor, 
and supporting read-only memory (RAM) and EEPROM. The 
high-performance programmable digital signal processor on the 
SPM is available for low-rate waveforms, software-controlled 
processing functions such as phased-locked loops (PLLs), and 
special-purpose applications such as fast Fourier transforms (FFTs). 

As depicted in the example in figure 5, the STRS platform 
supports an RFM with multiple transmitter and receiver chains. 
Each chain is specific to a particular frequency band. For 
example, the depiction shows two S-band transmitter and receiver 
subassemblies, as well as a direct-conversion X-band transmitter 
subassembly. Note that the RFM is further partitioned in this 
figure to explicitly highlight the transmitter and receiver chains. 
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Integrated GPM and SPM — Possibly in One FPGAor ASIC 


Spacecraft 

TT&C 

Interface 

Actel or 
ASIC 


General- 

Purpose 

Processor 


Code 

Storage 

PROM 

and 

EEPROM 


Telemetry 
and Test 
Interface 


Spacecraft 

Data 

Interface 



Small Mission Class 
(Extravehicular Activity) 

General 

Processing 

Module 

(GPM) 

Signal- 

Processing 

Module 

(SPM) 

Radio 

Frequency 

Module 

(RFM) 


Module 

Not 

Needed 


Digital 

to 


Transmit 

RF 

Analog 


(Filters- 

Amps) 








LL 




0 

x 


0 

0 


C 

<— 

Q_ 


0 

b 


c 



< 



; zn 

1 1 1 L 

]_ 

Clock 

Intprfprp 

1 

Signal-Processing Clock Distribution 

1 1 1 IU 1 1 C4 OO 




Integrated RFM With 
Reduced Complexity 


Figure 6. — Small-mission-class STRS hardware realization. 


This figure also shows the module interfaces. Detailed 
specification of these interfaces (as required by the hardware 
interface definition) ensures the open characteristic of the 
architecture and provides a path for scalability and technology 
insertion (including performance and component upgrades). 
The interfaces consist of both data- and control-plane constitu- 
ents. The control-plane interfaces transport the signals for 
component configuration to support waveform instantiation. 
The data-plane signals transport payload and telemetry and 
control data. Figure 6 shows a small-mission-class example. 
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Appendix — Acronyms 


ADC 

analog-to-digital converter 

LPF 

low-pass filter 

API 

application programming interface 

MAC 

Media Access Control 

ASIC 

application-specific integrated circuit 

MIPS 

Microprocessor without Interlocked Pipelined 

BPF 

band-pass filter 


Stages 

DAC 

digital-to-analog converter 

NCO 

Numerically Controlled Oscillator 

DSP 

Digital Signal Processing 

PCI 

Peripheral Component Interconnect 

EDAC 

Error Detection and Correction 

PHY 

physical 

EEPROM 

electrically erasable, programmable read-only 

PLL 

phase-locked loop 


memory 

PROM 

programmable read-only memory 

eft 

fast Fourier transform 

RAM 

read-only memory 

FPGA 

field-programmable gate array 

RF 

radiofrequency 

HAL 

Hardware Abstraction Layer 

RFIC 

radio frequency integrated circuit 

HID 

hardware interface description 

RFM 

Radio Frequency Module 

GPIO 

General-Purpose Input/Output 

RTOS 

real-time operating system 

GPM 

General Processing Module 

SDR 

software-defined radio 

GPP 

general-purpose processor 

SDRAM 

synchronous dynamic random access memory 

GPS 

Global Positioning System 

SPM 

Signal-Processing Module 

IC 

integrated circuit 

SRAM 

synchronous random access memory 

IF 

intermediate frequency 

STRS 

Space Telecommunications Radio System 

I/O 

input/output 

TT&C 

tracking, telemetry, and control 

LLC 

Logical Link Control 

TCXO 

Temperature Compensated Crystal Oscillator 

LNA 

low-noise amplifier 

TDRSS 

Tracking and Data Relay Satellite System 
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